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Abstract 



Compositional reasoning about a system means writing its specification as the par- 
allel composition of components and reasoning separately about each component. 
When distracting language issues are removed and the underlying mathematics is 
revealed, compositional reasoning is seen to be of little use. 
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1 Introduction 



When an engineer designs a bridge, she makes a mathematical model of it and 
reasons mathematically about her model. She might talk about calculating rather 
than reasoning, but calculating \fl to three decimal places is just a way of proving 
| V2 — 1-414| < 10~ 3 . The engineer reasons compositionally, using laws of math- 
ematics to decompose her calculations into small steps. She would probably be 
mystified by the concept of compositional reasoning about bridges, finding it hard 
to imagine any form of reasoning that was not compositional. 

Because computer systems can be built with software rather than girders and 
rivets, many computer scientists believe these systems should not be modeled with 
the ordinary mathematics used by engineers and scientists, but with something that 
looks vaguely like a programming language. We call such a language a pseudo- 
programming languages (PPL). Some PPLs, such as CSP, use constructs of ordi- 
nary programming languages. Others, like CCS, use more abstract notation. But, 
they have two defining properties: they are specially designed to model computer 
systems, and they are not meant to implement useful, real-world programs. 

When using a pseudo-programming language, compositional reasoning means 
writing a model as the composition of smaller pseudo-programs, and reasoning 
separately about those smaller pseudo-programs. If one believes in using PPLs to 
model computer systems, then it is natural to believe that decomposition should be 
done in terms of the PPL, so compositionality must be a Good Thing. 

We adopt the radical approach of modeling computer systems the way engi- 
neers model bridges — using mathematics. Compositionality is then a trivial con- 
sequence of the compositionality of ordinary mathematics. We will see that the 
compositional approaches based on pseudo-programming languages are analogous 
to performing calculations about a bridge design by decomposing it into smaller 
bridge designs. While this technique may occasionally be useful, it is hardly a 
good general approach to bridge design. 

2 The Mathematical Laws of Composition 

Mathematical reasoning is embodied in statements (also called theorems) and their 
proofs. The reasoning is hierarchical — the proof of a statement consists of a se- 
quence of statements, each with its proof. The decomposition stops at a level at 
which the proof is sufficiently obvious that it can be written as a short, simple 
paragraph. How rigorous the proof is depends on what "obvious" means. In the 
most rigorous proofs, it means simple enough so that even a computer can verify 
it. Less rigorous proofs assume a reader of greater intelligence (or greater faith). 
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We will use the notation introduced in [10] to write hierarchical proofs. 
Two fundamental laws of mathematics are used to decompose proofs: 

A-Composition A B v -Composition A C 

A^C B^C 

A^ B AC ivB^C 

Logicians have other names for these laws, but our subject is compositionality, so 
we adopt these names. A special case of v-composition is: 

Case-Analysis A A B =>• C 
Aa^B=>C 

A => C 

The propositional A- and v-composition rules have the following predicate-logic 
generalizations: 

V -Composition (i e S) A P =>• Q(i) 

P (Vt e 5 : Q(i)) 
3 -Composition (i e S) A P(i) =^ Q 

(3ieS : P(i))=> Q 
Another rule that is often used (under a very different name) is 

Act-Stupid A =>■ C 

A aB C 

We call it the act-stupid rule because it proves that A A B implies C by ignoring 
the hypothesis B. This rule is useful when B can't help in the proof, so we need 
only the hypothesis A. Applying it in a general method, when we don't know what 
A and B are, is usually a bad idea. 

3 Describing a System with Mathematics 

We now explain how to use mathematics to describe systems. We take as our 
example a digital clock that displays the hour and minute. For simplicity, we ignore 
the fact that a clock is supposed to tell the real time, and we instead just specify the 
sequence of times that it displays. A more formal explanation of the approach can 
be found in [9]. 
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3.1 Discrete Dynamic Systems 

Our clock is a dynamic system, meaning that it evolves over time. The classic way 
to model a dynamic system is by describing its state as a continuous function of 
time. Such a function would describe the continuum of states the display passes 
through when changing from 12:49 to 12:50. However, we view the clock as a 
discrete system. Discrete systems are, by definition, ones we consider to exhibit 
discrete state changes. Viewing the clock as a discrete system means ignoring the 
continuum of real states and pretending that it changes from 12:49 to 12:50 with- 
out passing through any intermediate state. We model the execution of a discrete 
system as a sequence of states. We call such a sequence a behavior. To describe a 
system, we describe all the behaviors that it can exhibit. 

3.2 An Hour Clock 
3.2.1 A First Attempt 

To illustrate how systems are described mathematically, we start with an even sim- 
pler example than the hour-minute clock — namely, a clock that displays only the 
hour. We describe its state by the value of the variable hr. A typical behavior of 
this system is 

[hr = 11] -> [hr= 12] -> [hr = 1] -> [hr = 2] -> ••• 

We describe all possible behaviors by an initial predicate that specifies the possible 
initial values of hr, and a next-state relation that specifies how the value of hr can 
change in any step (pair of successive states). 

The initial predicate is just hr e {1, . . . , 12}. The next-state relation is the 
following formula, in which hr denotes the old value and hr' denotes the new 
value. 

((hr = 12) A (hr' = 1)) v ((hr + 12) A (hr = hr + 1)) 

This kind of formula is easier to read when written with lists of conjuncts or dis- 
juncts, using indentation to eliminate parentheses: 

V A hr — 12 
A hr' = 1 

V A hr ^ 12 

A hr' = hr + 1 

There are many ways to write the same formula. Borrowing some notation from 
programming languages, we can write this next-state relation as 

hr' = if hr = 12 then 1 else hr + 1 
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This kind of formula, a Boolean-valued expression containing primed and un- 
primed variables, is called an action. 

Our model is easier to manipulate mathematically if it is written as a single 
formula. We can write it as 

A hr € {1, 12} (1) 
A □ (hr' - if hr - 12 then 1 else hr + 1) 

This is a temporal formula, meaning that it is true or false of a behavior. A state 
predicate like hr € {1 , . . . , 12} is true for a behavior iff it is true in the first state. A 
formula of the form □ N asserts that the action N holds on all steps of the behavior. 

By introducing the operator □, we have left the realm of everyday mathematics 
and entered the world of temporal logic. Temporal logic is more complicated than 
ordinary mathematics. Having a single formula as our mathematical description is 
worth the extra complication. However, we should use temporal reasoning as little 
as possible. In any event, temporal logic formulas are still much easier to reason 
about than programs in a pseudo-programming language. 



3.2.2 Stuttering 

Before adopting (1) as our mathematical description of the hour clock, we ask the 
question, what is a state? For a simple clock, the obvious answer is that a state is 
an assignment of values to the variable hr. What about a railroad station with a 
clock? To model a railroad station, we would use a number of additional variables, 
perhaps including a variable sig to record the state of a particular signal in the 
station. One possible behavior of the system might be 



hr = 11 
sig = "red" 



hr = 12 
sig = "red" 



hr = 12 
sig = "red" 



hr = 1 
sig = "red" 



hr = 12 
sig = "green" 



We would expect our description of a clock to describe the clock in the railroad 
station. However, formula (1) doesn't do this. It asserts that hr is incremented in 
every step, but the behavior of the railroad station with clock includes steps like 
the second and third, which change sig but leave hr unchanged. 

To write a single description that applies to any clock, we let a state consist 
of an assignment of values to all possible variables. In mathematics, the equation 
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x + y — 1, doesn't assert that there is no z. It simply says nothing about the value 
of z. In other words, the formula x + y — 1 is not an assertion about some universe 
containing only x and y. It is an assertion about a universe containing x, y, and all 
other variables; it constrains the values of only the variables x and y. 

Similarly, a mathematical formula that describes a clock should be an assertion 
not about the variable hr, but about the entire universe of possible variables. It 
should constrain the value only of hr and should allow arbitrary changes to the 
other variables — including changes that occur while the value of hr stays the same. 
We obtain such a formula by modifying (1) to allow "stuttering" steps that leave 
hr unchanged, obtaining: 

A/»re{l,...,12} (2) 
[-] /v hr' - if hr - 12 then 1 else hr + l\ 

\y hr' — hr J 

Clearly, every next-state relation we write is going to have a disjunct that leaves 
variables unchanged. So, it's convenient to introduce the notation that [A] v equals 
A v (V — v), where v' is obtained from the expression v by priming all its free 
variables. We can then write (2) more compactly as 

A hr e {1, 12} (3) 
A o[hr' = if hr - 12 then 1 else hr + l] hr 

This formula allows behaviors that stutter forever, such as 

[hr = 11] -> [hr = 12] -> [hr = 12] -> [hr = 12] -> ••• 

Such a behavior describes a stopped clock. It illustrates that we can assume all 
behaviors are infinite, because systems that halt are described by behaviors that 
end with infinite stuttering. But, we usually want our clocks not to stop. 



3.2.3 Fairness 

To describe a clock that doesn't stop, we must add a conjunct to (3) to rule out 
infinite stuttering. Experience has shown that the best way to write this conjunct is 
withfairness formulas. There are two types of fairness, weak and strong, expressed 
with the WF and SF operators that are defined as follows. 

WF V (A) If A A (V ^ v) is enabled forever, then infinitely many A A (v ' ^ v) 
steps must occur. 

SF„ 04) If A A (v ' ^ v) is enabled infinitely often, then infinitely many A A (t/ ^ 
v) steps must occur. 
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The v' ^ v conjuncts make it impossible to use WF or SF to write a formula that 
rules out finite stuttering. 

We can now write our description of the hour clock as the formula n, defined 

by 

N — hr' — if hr = 12 then 1 else hr + 1 

n = (hr € {1, . . . , 12}) A 0[N] hr A WF Ar (JV) 

The first two conjuncts of n (which equal (3)), express a safety property. Intu- 
itively, a safety property is characterized by any of the following equivalent condi- 
tions. 

• It asserts that the system never does something bad. 

• It asserts that the system starts in a good state and never takes a wrong step. 

• It is finitely refutable — if it is violated, then it is violated at some particular 
point in the behavior. 

The last conjunct of n (the WF formula) is an example of a liveness property. 
Intuitively, a liveness property is characterized by any of the following equivalent 
conditions. 

• It asserts that the system eventually does something good. 

• It asserts that the system eventually takes a good step. 

• It is not finitely refutable — it is possible to satisfy it after any finite portion 
of the behavior. 

Formal definitions of safety and liveness are due to Alpern and Schneider [4]. 

Safety properties are proved using only ordinary mathematics (plus a couple 
of lines of temporal reasoning). Liveness properties are proved by combining tem- 
poral logic with ordinary mathematics. Here, we will mostly ignore liveness and 
concentrate on safety properties. 

3.3 An Hour-Minute Clock 
3.3.1 The Internal Specification 

It is now straightforward to describe a clock with an hour and minute display. The 
two displays are represented by the values of the variables hr and min. To make 
the specification more interesting, we describe a clock in which the two displays 
don't change simultaneously when the hour changes. When the display changes 
from 8:59 to 9:00, it transiently reads 8:00 or 9:59. Since we are ignoring the 
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InitQ = A hr € {1, . . . , 12} 
A ram e {0, . . . , 59} 
A chg = FALSE 

M m — A —•((min = 0) A chg) 

A mm' — (ram + 1) mod 60 
A chg' = (min = 59) A —•chg 
A /ir' = hr 

Mh = A v (ram = 59) A ->chg 
V (min — 0) A c/ig 
A /ir' = (/ir mod 12) + 1 
A c/ig' — —•chg 
A mm' = min 

3> 4 a iraf* 

A n[M m V M h]{hr,min,chg) 
^T(hr,mm,chg)(M m V M h ) 

Figure 1 : The internal specification of an hour-minute clock. 

actual times at which state changes occur, these transient states are no different 
from the states when the clock displays the "correct" time. 

Figure 1 defines a formula O that describes the hour-minute clock. It uses an 
additional variable chg that equals TRUE when the display is in a transient state. 
Action M m describes the changing of min; action Mh describes the changing of 
hr. The testing and setting of chg by these actions is a bit tricky, but a little thought 
reveals what's going on. Action Mh introduces a gratuitous bit of cleverness to re- 
move the if/then construct from the specification of the new value of hr. The next- 
state relation for the hour-minute clock is M m v Mh, because a step of the clock 
increments either min or hr. Since (hr, min chg}' equals (hr', min', chg'}, it 
equals (hr, min, chg} iff hr, min, and, chg are all unchanged. 

3.3.2 Existential Quantification 

Formula $ of Figure 1 contains the free variables hr, min, and chg. However, 
the description of a clock should mention only hr and min, not chg. We need to 
"hide" chg. In mathematics, hiding means existential quantification. The formula 
3x : y = x 2 asserts that there is some value of x that makes y = x 2 true; it 
says nothing about the actual value of x. The formula describing an hour-minute 
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clock is 3 chg : 3>. The quantifier 3 is a temporal operator, asserting that there is 
a sequence of values of chg that makes O true. The precise definition of 3 is a bit 
subtle and can be found in [9]. 

3.4 Implementation and Implication 

An hour-minute clock implements an hour clock. (If we ask someone to build a 
device that displays the hour, we can't complain if the device also displays the 
minute.) Every behavior that satisfies the description of an hour-minute clock also 
satisfies the description of an hour clock. Formally, this means that the formula 
(3 chg : O) =>■ n is true. In mathematics, if something is true, we should be able to 
prove it. The rules of mathematics allow us to decompose the proof hierarchically. 
Here is the statement of the theorem, and the first two levels of its proof. (See [10] 
for an explanation of the proof style.) 

Theorem 1 (3 chg : <J>) =>- n 

(1)1. <D n 

(2)1. Initv hr e {1, 12} 

(2)2. a[M m v M h ] {hr , min , chg) =>■ a[N] hr 

(2)3. <D^WF Ar (JV) 

(2) 4. Q.E.D. 

PROOF: By (2) 1— (2)3 and the A-composition and act-stupid rules. 

(1) 2. Q.E.D. 

PROOF: By (1)1, the definition of O, and predicate logic 1 , since chg does not 
occur free in il. 

Let's now go deeper into the hierarchical proof. The proof of (2) 1 is trivial, since 
Init® contains the conjunct hr e {1, . . . , 12}. Proving liveness requires more 
temporal logic than we want to delve into here, so we will not show the proof of 

(2) 3 or of any other liveness properties. We expand the proof of (2)2 two more 
levels as follows. 

(2)2. n[M m v M h \ hr<mm<chg) =>■ a[N] hr 

(3) 1. [M m vM h ] { 

hr ,min,chg ) =>• [N]hr 

(4)1. M m ^[N] hr 
(4)2. M h [N] hr 

(4)3. ({hr, rain, chg)' = {hr, min, chg)) =>■ [iV]/j r 
(4)4. Q.E.D. 
Proof: By (4)l-(4)3 and the v-composition rule. 

'We are actually reasoning about the temporal operator 3 rather than ordinary existential quan- 
tification, but it obeys the usual rules of predicate logic. 
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(3)2. Q.E.D. A B 



Proof: By (3) 1 and the rule 



□ ,4 =^ UB 

The proof of (4)1 is easy, since M m implies hr' — hr. The proof of (4)3 is 
equally easy. The proof of (4)2 looks easy enough. 

(4)2. Mh [N] hr 

PROOF: M h =>• hr' = (hr mod 12) + 1 

=>. hr' — if hr — 12 then 1 else hr + 1 

4 N 

However, this proof is wrong ! The second implication is not valid. For example, 
if hr equals 25, then the first equation asserts hr' — 2, while the second asserts 
hr' = 26. The implication is valid only under the additional assumption hr € 
{1 12}. 

Define Inv to equal the predicate hr € {1, . . . , 12}. We must show that Inv is 
true throughout the execution, and use that fact in the proof of step (4)2. Here are 
the top levels of the corrected proof. 

(1)1. <D n 

(2)1. Initv =>• hr e {1, . . . , 12} 
(2)2. InitQ A a[M m v M h ] {hr/mm , chg) =^ nlnv 
(2)3. nlnv A D[M m V M h ] {hrtmintChg) n[N] hr 
(2)4. a Inv A <I> =>- WF Ar (jV) 

(2) 5. Q.E.D. 

PROOF: By (2) l-(2)4, and the A-composition and act-stupid rules. 

(1) 2. Q.E.D. 

PROOF: By (1)1, the definition of 3>, and predicate logic, since chg does not 
occur free in il. 

The high-level proofs of (2)2 and (2)3 are 

(2) 2. Initq, A n[M m V M h ] {hr/mmiChg) =>• Dim; 

(3) 1. Init<& => Inv 

(3)2. /nu A [M m v M A ]( Arimi „ iCA g) =>• 7m/ 
(3)3. Q.E.D. p p , 

Proof: By (3) 1, (3)2 and the rule 



P a n[A] v ap 
(2)3. nlnv A n[M m v M h ] {hrtmmtChg) □ [JV] Ar 
(3)1. /raA[¥ m VM A ]/ 
(3)2. Q.E.D. ^ ^ 
PROOF: By (3) 1 and the rules and n(A A B) = nA A UB 
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The further expansion of the proofs is straightforward and is left as an exercise 
for the diligent reader. 

3.5 Invariance and Step Simulation 

The part of the proof shown above is completely standard. It contains all the 
temporal-logic reasoning used in proving safety properties. The formula Inv satis- 
fying (2)2 is called an invariant. Substep (3)2 of step (2)3 is called proving step 
simulation. The invariant is crucial in this step and in step (2)4 (the proof of live- 
ness). In general, the hard parts of the proof are discovering the invariant, substep 
(3)2 of step (2)2 (the crucial step in the proof of invariance), step simulation, and 
liveness. 

In our example, Inv asserts that the value of hr always lies in the correct set. 
Computer scientists call this assertion type correctness, and call the set of correct 
values the type of hr. Hence, Inv is called a type-correctness invariant. This is 
the simplest form of invariant. Computer scientists usually add a type system just 
to handle this particular kind of invariant, since they tend to prefer formalisms that 
are more complicated and less powerful than simple mathematics. 

Most invariants express more interesting properties than just type correctness. 
The invariant captures the essence of what makes an implementation correct. Find- 
ing the right invariant, and proving its invariance, suffices to prove the desired 
safety properties of many concurrent algorithms. This is the basis of the first practi- 
cal method for reasoning about concurrent algorithms, which is due to Ashcroft [5]. 

3.6 A Formula by any Other Name 

We have been calling formulas like O and n "descriptions" or "models" of a sys- 
tem. It is customary to call them specifications. This term is sometimes reserved for 
high-level description of systems, with low-level descriptions being called imple- 
mentations. We make no distinction between specifications and implementations. 
They are all descriptions of a system at various levels of detail. We use the terms 
algorithm, description, model, and specification as different names for the same 
thing: a mathematical formula. 

4 Invariance in a Pseudo-Programming Language 

Invariance is a simple concept. We now show how a popular method for proving 
invariance in terms of a pseudo-programming language is a straightforward conse- 
quence of the rules of mathematics. 
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Figure 2: An Owicki-Gries style annotation of a process. 
4.1 The Owicki-Gries Method 

In the Owicki-Gries method [8, 11], the invariant is written as a program annota- 
tion. For simplicity, let's assume a multiprocess program in which each process i 
in a set P of processes repeatedly executes a sequence of atomic instructions S {l \, 
S^ n -i. The invariant is written as an annotation, in which each statement 
S^j is preceded by an assertion A^j, as shown in Figure 2. 

To make sense of this picture, we must translate it into mathematics. We first 
rewrite each operation S^j as an action, which we also call S (t) j. This rewriting 
is easy. For example, an assignment statement x : = x + 1 is written as the action 
(x' — x + 1) A ((. . .)' = (...}), where ". . ." is the list of other variables. We 
represent the program's control state with a variable pc, where pc[i] — j means 
that control in process i is immediately before statement S^j. The program and 
its invariant are then described by the formulas n and Inv of Figure 3. 

We can derive the Owicki-Gries rules for proving invariance by applying the 
proof rules we used before. The top-level proof is: 

Theorem 2 (Owicki-Gries) U=^ni 

(1)1. Init Inv 
(1)2. Inv A [N]( vb i tPC ) Inv' 
(2)1. Inv AN ^ Inv' 

(2)2. Inv A ((vbl, pc)' — (vbl, pc}) ^> Inv' 
(2)3. Q.E.D. 
Proof: By (2)1, (2)2, and the v-composition rule. 
(1)3. Q.E.D. 
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Init — A V i e P : pc[i] — 0 

A . . . [The initial conditions on program variables.] 

Go^j — A pc[i] — j 

A pc[i]' — (j + 1) mod n 

A V k e P : (£ # i) (pc[jfe]' - pc[£]) 

JV = 3 i € P, i € {0, . . . , n - 1} : Go^- A 5 (i) j 

f 6/ = (...) [The tuple of all program variables.] 

EI = Init A 0[N] {vb i t , pc) 

Inv = VieP, ie{0 n-1} : (pc[i] = j) =>• A M j 



Figure 3: The formulas describing the program and annotation of Figure 2. 



Proof: By (1)1, (1)2, and the rule 



P A [A] v P' 



P a a[A] v ap 

The hard part is the proof of (2)1. We first decompose it using the V - and 3 ■ 
composition rules. 

(2)1. Inv AN ^ Inv' 

(AieP 
Aj e {0,...,n-l} 
A Inv A Go®, A S {t) 3/ 

( a i e P 
A j € {0, n-l} 
a k e P 

a / e {0, n-l} 



(4)1. 



A Inv A Go^j A 5 (i) j 



Inv' 



((pc[k]' = l) (A (k) i)') 



(4)2. Q.E.D. 

PROOF: By (4) 1, the definition of Tnu, and the V -composition rule. 
(3)2. Q.E.D. 

PROOF: By (3) 1, the definition of N, and the 3 -composition rule. 

We prove (4)1 by cases, after first using propositional logic to simplify its state- 
ment. We let j © 1 equal (j + l) mod n. 
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(4)1 



/a i, k e P \ 
A j, I € {0, . . . , n— 1} 

A pc[&]' = / 

\a Inv A Go^j A 5 (i) j / 
(5)1. Case: i = k 
a i e P 

a j e {0, n — 1} 



(6)1. 



,A ^ A 5 (i) j 



(6)2. Q.E.D. 

PROOF: By (6)1, the level- (5) assumption, the definition of Tnu, and the 
act-stupid rule, since (pc[i]' = /) A Go^j implies (/ = j 0 1). 
(5)2. Case: i ^ A; 

(A i, k 6 P \ 
Aj,/e{0 n-1) (A (k \Y 

(6)2. Q.E.D. 

PROOF: By (6)1, the level- (5) assumption, the definition of Tnu, and the 
act-stupid rule, since (pc[k]' = /) A Go^'j implies (pc[k] — I), for k ^ i, 
and (pc[k] — I) A /nu implies ^4^^. 

We are finally left with the two subgoals numbered (6)1. Summarizing, we see 
that to prove Init =>■ a Inv, it suffices to prove the two conditions 



A 

A^j AA {k \ aS^j 



{A (k) lY 



for all i, k in P with i ^ k, and all j : , / in {0, . . . , n — 1}. These conditions are 
called Sequential Correctness and Interference Freedom, respectively. 



4.2 Why Bother? 

We now consider just what have has been accomplished by describing by prov- 
ing invariance in terms of a pseudo-programming language instead of directly in 
mathematics. 

Computer scientists are quick to point out that using " : =" instead of "— " 
avoids the need to state explicitly what variables are left unchanged. In practice, 
this reduces the length of a specification by anywhere from about 10% (for a very 
simple algorithm) to 4% (for a more complicated system). For this minor gain, it 
introduces the vexing problem of figuring out exactly what variables can and can- 
not be changed by executing x : = x + 1 . The obvious requirement that no other 
variable is changed would not allow us to implement x as the sum Ih * 2 32 + rh 
of two 32-bit values, since it forbids Ih and rh to change when x is incremented. 
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The difficulty of deciding what can and cannot be changed by an assignment state- 
ment is one of the things that makes the semantics of programming languages (both 
real and pseudo) complicated. By using mathematics, we avoid this problem com- 
pletely. 

A major achievement of the Owicki-Gries method is eliminating the explicit 
mention of the variable pc. By writing the invariant as an annotation, one can write 
A^j instead of (pc[i] —j) =>■ A^j. At the time, computer scientists seemed to 
think that mentioning pc was a sin. However, when reasoning about a concurrent 
algorithm, we must refer to the control state in the invariant. Owicki and Gries 
therefore had to introduce dummy variables to serve as euphemisms for pc. When 
using mathematics, any valid formula of the form Init A □[iV]„ =>■ DP, for a state 
predicate P, can be proved without adding dummy variables. 

One major drawback of the Owicki-Gries method arises from the use of the 
act-stupid rule in the proofs of the two steps numbered (6)2. The rule was applied 
without regard for whether the hypotheses being ignored are useful. This means 
that there are annotations for which step (2)1 (which asserts N A Inv =>■ Inv') is 
valid but cannot be proved with the Owicki-Gries method. Such invariants must be 
rewritten as different, more complicated annotations. 

Perhaps the thing about the Owicki-Gries method is that it obscures the un- 
derlying concept of invariance. We refer the reader to [6] for an example of how 
complicated this simple concept becomes when expressed in terms of a pseudo- 
programming language. In 1976, the Owicki-Gries method seemed like a major 
advance over Ashcroft's simple notion of invariance. We have since learned better. 

5 Refinement 

5.1 Refinement in General 

We showed above that an hour-minute clock implements an hour clock by proving 
(3 chg : <t>) =>• n. That proof does not illustrate the general case of proving that 
one specification implements another because the higher-level specification n has 
no internal (bound) variable. The general case is covered by the following proof 
outline, where x, y, and z denote arbitrary tuples of variables, and the internal 
variables y and z of the two specifications are distinct from the free variables x. 
The proof involves finding a function/, which is called a refinement mapping [1]. 

Theorem 3 (Refinement) (Sy : ®(x,y)) =>• (Sz : Yl(x,z)) 

Let: J = f(x, y) 
(1)1. <t>(x, y) Yl(x,7) 
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(1)2. d>(x,y) (Bz : Yl(x,z)) 

PROOF: By (1)1 and predicate logic, since the variables of z are distinct from 
those of x. 

The proof of step (1)1 has the same structure as in our clock example. 

5.2 Hierarchical Refinement 

In mathematics, it is common to prove a theorem of the form P =>■ Q by in- 
troducing a new formula R and proving P =>• R and i? =>• Q. We can prove 
that a lower-level specification By : <$>(x,y) implies a higher-level specification 
3 z : il (x, z) by introducing an intermediate-level specification Bw : ^(x, w) and 
using the following proof outline. 

Let: ty(x, w) = ... 
(1)1. (By : <P(x,y)) =>• (3w : *(a;, w)) 
Let: w = ^(a;, y) 

(1)2. (Bw : *(a;,w)) =>• (Bz : n(a;, ^)) 
Let: J = h(x, w) 

(1)3. Q.E.D. 
Proof: By (1)1 and (1)2. 

This proof method is called hierarchical decomposition. It's a good way to explain 
a proof. By using a sequence multiple intermediate specifications, each differing 
from the next in only one aspect, we can decompose the proof into conceptually 
simple steps. 

Although it is a useful pedagogical tool, hierarchical decomposition does not 
simplify the total proof. In fact, it usually adds extra work. Hierarchical decom- 
position adds the task of writing the extra intermediate-level specification. It also 
restricts how the proof is decomposed. The single refinement mapping / in the 
outline of the direct proof can be defined in terms of the two mappings g and h of 
the hierarchical proof by / (x , y) — h(x, g(x, y)). The steps of a hierarchical proof 
can then be reshuffled to form a particular way of decomposing the lower levels of 
the direct proof. However, there could be better ways to decompose those levels. 

5.3 Interface Refinement 

We have said that implementation is implication. For this to be true, the two speci- 
fications must have the same free variables. If the high-level specification describes 
the sending of messages on a network whose state is represented by the variable 
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net, then the low-level specification must also describe the sending of messages on 

net. 

We often implement a specification by refining the interface. For example, we 
might implement a specification £ (net) of sending messages on net by a specifi- 
cation A(tran) of sending packets on a "transport layer" whose state is represented 
by a variable tran. A single message could be broken into multiple packets. Cor- 
rectness of the implementation cannot mean validity of A(iran) =>• E(nei), since 
K(tran) and S(nef) have different free variables. 

To define what it means for A(iran) to implement X (nei), we must first define 
what it means for sending a set of packets to represent the sending of a message. 
This definition is written as a temporal formula R(net, trans), which is true of 
a behavior iff the sequence of values of trans represents the sending of packets 
that correspond to the sending of messages represented by the sequence of values 
of net. We call R an interface refinement. For R to be a sensible interface refine- 
ment, the formula K(trans) =>• 3 net : R(net, trans) must be valid, meaning that 
every set of packet transmissions allowed by A(trans) represents some set of mes- 
sage transmissions. We say that A(tran) implements S(nef) under the interface 
refinement R(net, trans) iff A(tran) A R(net, trans) implies E(nef). 

6 Decomposing Specifications 

Pseudo-programming languages usually have some parallel composition operator 
||, where Si 115*2 is the parallel composition of specifications Si and 5*2. We ob- 
served in our hour-clock example that a mathematical specification Si does not 
describe only a particular system; rather, it describes a universe containing (the 
variables that represent) the system. Composing two systems means ensuring that 
the universe satisfies both of their specifications. Hence, when the specifications 
5*1 and 5*2 are mathematical formulas, their composition is just Si A 5*2. 

6.1 Decomposing a Clock into its Hour and Minute Displays 

We illustrate how composition becomes conjunction by specifying the hour-minute 
clock as the conjunction of the specifications of an hour process and a minute 
process. It is simpler to do this if each variable is modified by only one process. So, 
we rewrite the specification of the hour-minute clock by replacing the variable chg 
with the expression chgh ^ chg m , where chgh and chg m are two new variables, 
chgh being modified by the hour process and chg m by the minute process. The 
new specification is 3 chgh, chg m : *I>, where is defined in Figure 4. Proving 
that this specification is equivalent to 3 chg : O, where <I> is defined in Figure 1, 
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Inity — A hr e {1, . . . , 12} 
A ram e {0, . . . , 59} 

A chg m — chgh = TRUE 

N m — A ->((min = 0) A (c/i# m ^ chg h )) 
A mm' = (mm + 1) mod 60 
A chg' m = if min — 59 then —>chg m else c/ig/j 
A (hr, chg h )' = (hr, chg h ) 

N h = A V (mm - 59) A (chg m = chg h ) 
V (ram = 0) A (c/i# m ^ chg h ) 
A /ir' = (/ir mod 12) + 1 
A chg' h =^chg h 
A (rain, chg m )' — (rain, chg m ) 

* 4 a Inity 

A D[7V m V N k](hr, min, chg m , chg h ) 
A WF(Jr, mm, cAg m , chg h )(N m V TV^) 

Figure 4: Another internal specification of the hour-minute clock. 

is left as a nice exercise for the reader. The proof that 3 chgh, chg m : *I> implies 
3 chg : O uses the refinement mapping chg — (chgh 7^ chg m ). The proof of the 
converse implication uses the refinement mapping 

chgh — chg A (min — 59) chg m — chg A (min — 0) 

The specifications ^>h and * m of the hour and minute processes appear in Figure 5. 
We now sketch the proof that *I> is the composition of those two specifications. 

Theorem 4 * = \p m a Hr h 

Init m — A min e {0, . . . , 59} 
A chg m = TRUE 

Init h = A hr e {1, . . . , 12} 
A chgh = TRUE 

* A = Inith A a[N h ](hr, chg h ) AWF, (N h ) 

^ m — Init m A D [7V m ] ( min , chg m ) A WF( mm 7 chg m )(-^ m) 

Figure 5: Definition of the specifications and *I> m . 
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(1)1. Inity = Init m A Inith 

(1)2. 0[N m V Nh](hr, min, chg m , chg h ) = D m ]( m i n , chg m ) A □ [N h] ( hr, chg h ) 



(1)3. A* WF {mm , chgm) (N m ) AWF {hr , chgh) (N h ) 
A * m A * A =>. WF ( 

Ar. min, chg m , cA^/j ) 

(N m vN h ) 

(1)4. Q.E.D. 
Proof: By (1)1-(1)3. 

Ignoring liveness (step (1)3), the hard part is proving (2)1. This step is an imme- 
diate consequence of the following propositional logic tautology, which we call the 
V o A rule. 



Its proof is left as an exercise for the reader. 
6.2 Decomposing Proofs 

In pseudo-programming language terminology, a compositional proof of refine- 
ment (implementation) is one performed by breaking a specification into the paral- 
lel composition of processes and separately proving the refinement of each process. 

The most naive translation of this into mathematics is that we want to prove 
A =>• S by writing S as Si A S 2 and proving A =>• Si and A =>• S 2 separately. 
Such a decomposition accomplishes little. The lower-level specification A is usu- 
ally much more complicated than the higher-level specification S , so decomposing 
S is of no interest. 

A slightly less naive translation of compositional reasoning into mathematics 
involves writing both A and S as compositions. This leads to the following proof 
of A S. 



(1)1. aA = Ai aA 2 

A S = Si A S2 

Proof: Use the v a rule. 
(1)2. Ai Si 
(1)3. A 2 =» S 2 
(1)4. Q.E.D. 

PROOF: By (1)1-(1)3 and the A-composition and act-stupid rules. 



(2)1. [^m V N h](hr , min, chg m , c 

(2)2. Q.E.D. 
Proof: By (2) 1 and the rules 




Ni A (j / i) =>• (t/- = Vj) for 1 < i,j < n 



[N l V . . . V N n \ vu _ Vn) = [JViL, A ... A[N n ] v 
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The use of the act-stupid rule in the final step tells us that we have a problem. 
Indeed, this method works only in the most trivial case. Proving each of the im- 
plications A, =>■ S; requires proving A, =>■ Invi for some invariant Inv{. Except 
when each process accesses only its own variables, so there is no communication 
between the two processes, Invi will have to mention the variables of both pro- 
cesses. As our clock example illustrates, the next-state relation of each process's 
specification allows arbitrary changes to the other process's variables. Hence, A, 
can't imply any nontrivial invariant that mentions the other process's variables. So, 
this proof method doesn't work. 

Think of each process A, as the other process's environment. We can't prove 
A, =>• because it asserts that A, implements in the presence of arbitrary be- 
havior by its environment — that is, arbitrary changes to the environment variables. 
No real process works in the face of completely arbitrary environment behavior. 

Our next attempt at compositional reasoning is to write a specification E{ of the 
assumptions that process i requires of its environment and prove A, A E{ =>■ 
We hope that one process doesn't depend on all the details of the other process's 
specification, so Ei will be much simpler than the other process's specification 
A2-i. We can then prove A S using the following propositional logic tautol- 
ogy- 

Ai AA 2 =>• E\ Ai AA 2 =>■ E 2 
AiAffi Si A 2 aE 2 S 2 

Ai A A 2 =>■ Si A S 2 

However, this requires proving A =>• Ei, so we still have to reason about the 
complete lower-level specification A. What we need is a proof rule of the following 
form 

Ei AE 2 =>■ Ei SiAS 2 =>• E 2 (4) 
Ai A E\ =>■ Si A 2 A E 2 =>• S 2 

Ai A A 2 =>• Si A S 2 

In this rule, the hypotheses A =>■ Ei of the previous rule are replaced by S =>• E{. 
This is a great improvement because S is usually much simpler than A. A rule like 
(4) is called a decomposition theorem. 

Unfortunately, (4) is not valid for arbitrary formulas. (For example, let the A, 
equal TRUE and all the other formulas equal FALSE.) Roughly speaking, (4) is valid 
if all the properties are safety properties, and if and Ei modify disjoint sets of 
variables, for each i. A more complicated version of the rule allows the A, and 
to include liveness properties; and the condition that S and Ei modify disjoint sets 
of variables can be replaced by a weaker, more complicated requirement. More- 
over, everything generalizes from two conjuncts to n in a straightforward way. All 
the details can be found in [2]. 
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6.3 Why Bother? 



What have we accomplished by using a decomposition theorem of the form (4)? As 
our clock example shows, writing a specification as the conjunction of n processes 
rests on an equivalence of the form 

□ [iViV...vJV„] < „ 1 ,...„ n> = □[iVi]„ 1 A... AD[JV„]„ n 

Replacing the left-hand side by the right-hand side essentially means changing 
from disjunctive normal form to conjunctive normal form. In a proof, this replaces 
v-composition with A-composition. Such a trivial transformation is not going to 
simplify a proof. It just changes the high-level structure of the proof and rearranges 
the lower-level steps. 

Not only does this transformation not simplify the final proof, it may add extra 
work. We have to invent the environment specifications E{, and we have to check 
the hypotheses of the decomposition theorem. Moreover, handling liveness can be 
problematic. In the best of all possible cases, the specifications E{ will provide 
useful abstractions, the extra hypotheses will follow directly from existing theo- 
rems, and the decomposition theorem will handle the liveness properties. In this 
best of all possible scenarios, we still wind up only doing exactly the same proof 
steps as we would in proving the implementation directly without decomposing it. 

This form of decomposition is popular among computer scientists because it 
can be done in a pseudo-programming language. A conjunction of complete speci- 
fications like Ai A A2 corresponds to parallel composition, which can be written in 
a PPL as Ai || A2. The PPL is often sufficiently inexpressive that all the specifica- 
tions one can write trivially satisfy the hypotheses of the decomposition theorem. 
For example, the complications introduced by liveness are avoided if the PPL pro- 
vides no way to express liveness. 

Many computer scientists prefer to do as much of a proof as possible in the 
pseudo-programming language, using its special-purpose rules, before being forced 
to enter the realm of mathematics with its simple, powerful laws. They denigrate 
the use of ordinary mathematics as mere "semantic reasoning". Because mathe- 
matics can so easily express the underlying semantics of a pseudo-programming 
language, any proof in the PPL can be translated to a semantic proof. Any law for 
manipulating language constructs will have a counterpart that is a theorem of ordi- 
nary mathematics for manipulating a particular class of formulas. Mathematics can 
also provide methods of reasoning that have no counterpart in the PPL because of 
the PPL's limited expressiveness. For example, because it can directly mention the 
control state, an invariance proof based on ordinary mathematics is often simpler 
than one using the Owicki-Gries method. 
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Many computer scientists believe that their favorite pseudo-programming lan- 
guage is better than mathematics because it provides wonderful abstractions such 
as message passing, or synchronous communication, or objects, or some other pop- 
ular fad. For centuries, bridge builders, rocket scientists, nuclear physicists, and 
number theorists have used their own abstractions. They have all expressed those 
abstractions directly in mathematics, and have reasoned "at the semantic level". 
Only computer scientists have felt the need to invent new languages for reasoning 
about the objects they study. 

Two empirical laws seem to govern the difficulty of proving the correctness of 
an implementation, and no pseudo-programming language is likely to circumvent 
them: (1) the length of a proof is proportional to the product of the length of the 
low-level specification and the length of the invariant, and (2) the length of the in- 
variant is proportional to the length of the low-level specification. Thus, the length 
of the proof is quadratic in the length of the low-level specification. To appreci- 
ate what this means, consider two examples. The specification of the lazy caching 
algorithm of Afek, Brown, Merritt [3], a typical high-level algorithm, is 50 lines 
long. The specification of the cache coherence protocol for a new computer that 
we worked on is 1900 lines long. We expect the lengths of the two corresponding 
correctness proofs to differ by a factor of 1500. 

The most effective way to reduce the length of an implementation proof is to 
reduce the length of the low-level specification. A specification is a mathematical 
abstraction of a real system. When writing the specification, we must choose the 
level of abstraction. A higher-level abstraction yields a shorter specification. But 
a higher-level abstraction leaves out details of the real system, and a proof cannot 
detect errors in omitted details. Verifying a real system involves a tradeoff between 
the level of detail and the size (and hence difficulty) of the proof. 

A quadratic relation between one length and another implies the existence of 
a constant factor. Reducing this constant factor will shorten the proof. There are 
several ways to do this. One is to use better abstractions. The right abstraction can 
make a big difference in the difficulty of a proof. However, unless one has been 
really stupid, inventing a clever new abstraction is unlikely to help by more than a 
factor of five. Another way to shorten a proof is to be less rigorous, which means 
stopping a hierarchical proof one or more levels sooner. (For real systems, proofs 
reach a depth of perhaps 12 to 20 levels.) Choosing the depth of a proof provides 
a tradeoff between its length and its reliability. There are also silly ways to reduce 
the size of a proof, such as using small print or writing unstructured, hand-waving 
proofs (which are known to be completely unreliable). 

Reducing the constant factor still does not alter the essential quadratic nature 
of the problem. With systems getting ever more complicated, people who try to 
verify them must run very hard to stay in the same place. Philosophically motivated 
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theories of compositionality will not help. 

6.4 When a Decomposition Theorem is Worth the Bother 

As we have observed, using a decomposition theorem can only increase the total 
amount of work involved in proving that one specification implements another. 
There is one case in which it's worth doing the extra work: when the computer does 
a lot of it for you. If we decompose the specifications A and £ into n conjuncts 
A, and S,-, the hypotheses of the decomposition theorem become £ =>• E{ and 
A, A E{ =>■ for i — 1, . . . , n. The specification A is broken into the smaller 
components A,-. Sometimes, these components will be small enough that the proof 
of AiAEi can be done by model checking — using a computer to examine all 

possible equivalence classes of behaviors. In that case, the extra work introduced 
by decomposition will be more than offset by the enormous benefit of using model 
checking instead of human reasoning. An example of such a decomposition is 
described in [7]. 

7 Composing Specifications 

There is one situation in which compositional reasoning cannot be avoided: when 
one wants to reason about a component that may be used in several different sys- 
tems. 

The specifications we have described thus far have been complete-system spec- 
ifications. Such specifications describe all behaviors in which both the system and 
its environment behave correctly. They can be written in the form S A E, where 
S describes the system and E the environment. For example, if we take the com- 
ponent to be our clock example's hour process, then S is the formula ^ and E is 
* m . (The hour process's environment consists of the minute process.) 

If a component may be used in multiple systems, we need to write an open- 
system specification — one that specifies the component itself, not the complete sys- 
tem containing it. Intuitively, the component's specification asserts that it satisfies 
S if the environment satisfies E. This suggests that the component's open-system 
specification should be the formula E =>■ S. This specification allows behaviors 
in which the system misbehaves, if the environment also misbehaves. It turns out 
to be convenient to rule out behaviors in which the system misbehaves first. (Such 
behaviors could never be allowed by a real implementation, which cannot know in 
advance that the environment will misbehave.) We therefore take as the specifica- 
tion the formula E ^> S, which is satisfied by a behavior in which S holds as long 
as E does. The precise definition of -h> and the precise statement of the results 
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about open-system specifications can be found in [2]. 

The basic problem of compositional reasoning is showing that the composi- 
tion of component specifications satisfies a higher-level specification. This means 
proving that the conjunction of specifications of the form E -±> S implies another 
specification of that form. For two components, the proof rule we want is: 

E A 5*1 A 5*2 =>• E\ A Ei A S 

{E\ SO A (E 2 5> S 2 ) => (E5>S) 

Such a rule is called a composition theorem. As with the decomposition theorem 
(4), it is valid only for safety properties under certain disjointness assumptions; a 
more complicated version is required if S and the Si include liveness properties. 

Composition of open-system specifications is an attractive problem, having ob- 
vious application to reusable software and other trendy concerns. But in 1997, the 
unfortunate reality is that engineers rarely specify and reason formally about the 
systems they build. It is naive to expect them to go to the extra effort of prov- 
ing properties of open-system component specifications because they might re-use 
those components in other systems. It seems unlikely that reasoning about the 
composition of open-system specifications will be a practical concern within the 
next 15 years. Formal specifications of systems, with no accompanying verifica- 
tion, may become common sooner. However, the difference between the open- 
system specification E M and the complete-system specification E A M is one 
symbol — hardly a major concern in a specification that may be 50 or 200 pages 
long. 

8 Conclusion 

What should we do if faced with the problem of finding errors in the design of a 
real system? The complete design will almost always be too complicated to handle 
by formal methods. We must reason about an abstraction that represents as much 
of the design as possible, given the limited time and manpower available. 

The ideal approach is to let a computer do the verification, which means model 
checking. Model checkers can handle only a limited class of specifications. These 
specifications are generally small and simple enough that it makes little differ- 
ence in what language they are written — conventional mathematics or pseudo- 
programming languages should work fine. For many systems, abstractions that 
are amenable to model checking omit too many important aspects of the design. 
Human reasoning — that is, mathematical proof — is then needed. Occasionally, 
this reasoning can be restricted to rewriting the specification as the composition of 
multiple processes, decomposing the problem into subproblems suitable for model 
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checking. In many cases, such a decomposition is not feasible, and mathematical 
reasoning is the only option. 

Any proof in mathematics is compositional — a hierarchical decomposition of 
the desired result into simpler subgoals. A sensible method of writing proofs will 
make that hierarchical decomposition explicit, permitting a tradeoff between the 
length of the proof and its rigor. Mathematics provides more general and more 
powerful ways of decomposing a proof than just writing a specification as the par- 
allel composition of separate components. That particular form of decomposition 
is popular only because it can be expressed in terms of the pseudo-programming 
languages favored by computer scientists. 

Mathematics has been developed over two millennia as the best approach to 
rigorous human reasoning. A couple of decades of pseudo-programming language 
design poses no threat to its pre-eminence. The best way to reason mathematically 
is to use mathematics, not a pseudo-programming language. 
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